It is a common scenario in networked computer systems for untrusted (or only partially trusted) program code to be received over the network (e.g., the Internet) and executed on a user's computer. Such untrusted code may include without limitation application updates, applets, plug-ins, user macros in documents, command-line scripts, programs downloaded from the network, etc. For example, a user may download a stock ticker applet written in a platform-independent intermediate language to be executed within a managed execution environment on the user's computer.
However, because the origin of the downloaded applet is unknown or untrusted, the user may not be confident in the safety of executing the applet on his or her computer, and rightly so—the applet code may include malicious instructions intended to steal or destroy the user's data. Alternatively, while the code may not be malicious, improperly implemented code may inadvertently access or destroy the user's data. Accordingly, such managed execution environments commonly embed a security framework to protect the user's system.
Such security frameworks typically include a layered permission-based infrastructure. Varying permissions are attributed to each piece of code to be executed within the managed execution environment. Only code having the necessary permissions are allowed to execute various operations (e.g., an operation that accesses a system resource).
Also, as part of the layered aspect of the security framework, untrusted code is isolated from sensitive system functions by more trusted components. In one circumstance, an exemplary untrusted applet cannot directly access the file system to modify a file. Instead, to modify a file in the file system, the untrusted applet must call a trusted component (e.g., an object in a file system library provided by the operating system vendor), which can access the file system.
However, the trusted component is also designed to adhere strictly to the constraints of the security framework. Therefore, unless the untrusted applet is attributed with adequate permissions to access the file system, and specifically to modify the file, the trusted component should deny the requested access. Moreover, the permissions required to access the file system may vary depending on the type of access requested. For example, weak permissions may be required to access a cookie file in a directory of cookies, while strong permissions may be required to delete private user data elsewhere in the file system.
A significant strength of this security framework lies within the strict adherence of the trusted components to the constraints of the security framework. However, for a variety of reasons, even the security of highly trusted components may be compromised in the presence of arbitrary untrusted code or improperly implemented trusted code (e.g., when the highly trusted code does not actually adhere strictly to the constraints of the security framework).